My no-std use case only requires &str to work. This is fine for me.
I will "experimentally" use this branch in the project that needs it tomorrow. Up to you if you want to wait for that.
At first glance this looks good to me.

Could you consider to do the seals the way I did them?
RustRover, a IDE which many people use for rust, isnt smart enough to realize that the functions are sealed.
Since we implement them for a common type string and friends, it will recommend them, this may be annoying to some people.

The way I sealed them works for rust rover.
Again this is not a problem for me personally. Its just, I know people that would nitpick this.

Unfortunately the supertrait sealing makes the implementers not visible in the documentation, which I think is crucial to have here. We can explore other options, although at the same time: are these suggestions showing up even when the trait isn't imported? There should rarely be a need for anybody to import the trait.

Hm, maybe we could still use super trait and have the methods on it, but instead of having a generic impl<T: SealedTrait> Trait for T, we'd have implementations of Trait for each individual type too... Let me try.

The suggestion shows up when the trait is not imported. Its enough to have libloading in Cargo.toml.
It doesn't even need to be used at all.

Its not that big of a deal, just can be confusing.
Also, why does this showing up in the documentation matter?
The user of libloading should never call these functions, they are something internal to the crate.

I happen to coincidentally maintain an unrelated crate that requires usage of String and friends in CESU-8 byte encoding.
Sometimes CESU8 and Utf-8 overlap so I only need to allocate a buffer "sometimes".
There I chose a similar trait+closure approch and found it quite nice that my internal method is hidden in the doc.
At least my approach is, if the user is not supposed to call it then he shouldnt need to know about it.

Also, why does this showing up in the documentation matter?
The user of libloading should never call these functions, they are something internal to the crate.

That's how you learn about which types you can use to pass in into Library::new or Library::get. One could argue that listing them manually somewhere would be good enough, but nothing really beats being able to click on AsSymbol and finding the following:

The internal method does not show up (in fact I especially hid it with doc(hidden) in the sealed method approach.) That said my idea of adjusting supertrait method does also work for doc generation so I'm happy to switch back to supertrait method.

Ah rustdoc must have not been smart enough to see my generic impl for T, that makes sense. Yes them showing up in the doc like that is indeed more important than not potentically annoying RustRover users (like me).

Good thinking with the manual impl, glad we could get that sorted out. I am still working on unrelated things so I can actually compile my inteded library with no-std and libloading as I intend to. I will report back once I have succeeded (or failed, but that is unlikely).

Alright all is working as expected for my use case. RustRover is also quiet now.
You can go ahead and merge this.

Was once again a pleasure working on this with you and I also learned something new!
Thank you very much.